COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	Notes about new ARPAnet software
C00009 00003	Priorities
C00011 ENDMK
C⊗;
Notes about new ARPAnet software

I.	The official sources for the new ARPAnet software live on NET,MRC.
Eventually they may be moved to NET,SYS; and the old stuff reaped.  Much
of it might be used for quite a while yet.

II.	Everything should use the NETWRK package instead of trying to hack
the network itself.  The reason for this is that NETWRK can provide a black
box for user programs, and if the system changes (such as being rewritten
from the ground up) then all that would have to be done is recompile the
programs which use NETWRK.  The MIDAS version of NETWRK lives on NET,MRC
and the FAIL version on SUB,SYS.  All development of the NETWRK package is
to be done on the MIDAS version, and the FAIL version updated after all the
dust settles.  The theory of this is that the network liaison/hacker (ie,
me) will stomp on NETWRK and the programs he maintains (TELNET, etc.) will
be the ones which are affected by a screw; which he can take care of.  While
the FAIL version may be used by users, or only semi-network wizards (such
as BH with MAIL and FTP) and it would be much harder to fix things if they
get screwed.

III.	Since everything uses NETWRK everybody should use HOSTS1 and not
NAMES.  Things which use NAMES should be fixed or rewritten.  Eventually
maintainence of NAMES will cease, although the file will remain around for
a while to allow for a transition period.

IV.	Once Dialnet happens I suspect DIAL will soon go away.  PTYJOB should
then be set loose from TELNET, after which I guess we can flush the TELNET
code and make an FTP.FAI out of it.  Probably a lot of cleaning up can happen
there too; although FTP is a special case since it has data sockets as well
as TELNET sockets.  Eventually that will be rewritten too; but that has about
the same priority as rewriting DFTP right now since FTP uses NETWRK to the
extend that it uses HOSTS1, which is what is essential.

V.	The whole business about servers sucks totally and has to be done
differently.  I propose the individual server do the actual listening.  When
an RFC comes in, the MONITOR (not a LOGGER dearie; the LOGGER should go away)
looks for a file on NET,SYS of the form RFCnnn.DMP and fires it up.  There
are many advantages to this; but the first and foremost is that it is more
robust than having a logger.  Today, the LOGGER had to be executed to let
any network users in since it was wedged with the AMES Tip.

VI.	PTYNET UUO to connect a PTY to a pair of network sockets.  It should
be something like
	PTYNET ptych,[outskt,,inpskt]
	 <error like sockets in fucked up state or something>
	<return when something "interesting" happens>
Interesting is defined as a 377 byte.  We could use 1.8 to mean interesting
for the old protocol but that loses for us (ITS uses 1.8, but doesn't use
binary mode; the SUPDUP protocol uses 7-bit bytes on input partially because
of hardware, partially because of this screw.

VII.	One problem with PTYNETting is that you want to get only as many bytes
as you need, then send everything back to the PTY.  I think the best way to do
it is not to oblige the server to hack the PTY itself in any form, but rather
simply to have some form of unit mode I/O, like general purpose TTYUUOs, to
the network for this purpose.  But it may cause problems with the idiotic
way buffers are done in the system (garp!).  Of course, PTYNET should NEVER
but EVER disengage the outskt connection!!!!!!!!!!!

VIII.	Something has to be done about output resets as well.  TELNET is now
smart about them, but the server is not.  The problem is quite difficult.
Not too long ago REM complained that he was being horribly screwed when net-
hopping with output resets, since TELNET has moby TTY output buffers and while
TELNET was aborting almost immediately, it had already dumped its stuff to the
network.  I wasn't too sympathetic, but on the other hand, it would be nice to
be able to have output aborted reasonably quickly.  The thing is that ↑O and
CLRBFO will not do it, but SYNCH AO will (well, it has to).

IX.	String I/O and # of bytes available UUO's too need to be implemented.
This would save infinite screws with TELNET.  TELSER should not have to worry
about it since it is PTYNET'd all the time, although in handling network
commands it is another story.
Priorities

I.	Make MAIL use NETWRK as much as possible.

II.	New TELNET server!

III.	Give TELNET a Datamedia simulator and old protocol capability so old
TELNET can be flushed.  This means finishing DPYRTS and more pressure for a
LEXYPS UUO.

IV.	NHOST should be flushed and HOST should be rewritten properly.

V.	Things like SIMPER needs to be fixed, ditto for WHERE.  Other things
like TALK should be rewritten.  Check to see if anybody really uses Tovar's
NGP server and if Tovar isn't interested in fixing it, maybe flush it?

VI.	That old stuff-going-out being 5 times slower than stuff-coming-in
bug has to be fixed once and for all.